Subject: Re: Real Resources

From: Matthew Finlayson <[email-masked]>
Date: Tue, 15 Aug 95 18:53:00 BST

I've included our responses below.

 ----------
>
> >     o Very few sacred cows are contained within the proposal. This 
implies
> >       that there are some, and indeed there are:
>
> Totally agree on this point. I am not fixed to any particular
> specifics to provide this function, but feel that the function, and
> the objectives that you have outlined are essential to the continued
> use of APPN (and our pay packets !).
>

As we said in our initial response, we agree that the functionality would be 
extremely valuable.

> > > -  We think that the DS architecture makes it unsuitable for a lot of 
the
> > >   additional function the proposal introduces.
> >
> > It appears that only minor changes are necessary to use DS for the 
purposes
> > outlined in the proposal. Given that, I am not sure I fully understand
> > why DS would not be the correct place to address this functionality.
> > However, as I said, no sacred cows.
>
> I also have problems working out why DS is not suitable for this
> function. I have read the patents involved, and indeed it appears that
> DS *was* originally designed to cope with this functionality, but the
> architecture team determined that it was not necessary
> immediately. Probably a good choice at the time, but it is time to
> move on. I believe the patent architecture team were correct - this is
> a function that is well suited to the current architecture. There are
> also factions within IBM that would like DS expanded to perform this
> function.
>

This may well be the case, but we believe there are fundamental and 
insoluble back compatibility problems trying to support multiple positive 
responses in DS.

> > > -  The proposal suggests that the locate buffer size be increased to 
32Kb.
> > >   We feel that this is far too large (and I will discuss this later) 
but
> > >   it will also cause interoperability problems.  If an NN tries to 
send a
> > >   current-level NN more data than 1024 bytes (the current limit) then 
the
> > >   receiving NN will not accept it (and may well bring down CP-CP 
sessions
> > >due
> > >   to the protocol violation).  This would cause particular problems if 
the
> > >   current-level NN was a route to a CDS (which could be expected to
> > >   return large amounts of data).
> > >
> >
> > This would only be a requirement at the End Node were the locate/search
> > originated. Since the End Node would be a new implementation supporting 
this
> > functionality, this does not appear to be a problem. There is a
> > corresponding
> > implication at the NN server. However, since the NN server would also be 
a
> > new
> > implementation supporting this functionality, it does not appear to be a
> > problem here either. None of the intermediate nodes should be concerned
> > with this. Am I missing something?
>
> No, I think the guys at DCL have it right. Since the aim is to rely on
> CDS to answer most queries, all NNs in the path between ONN and CDS
> need to support large responses.
>

Agreed.  Similarly on a broadcast search, any individual node may wish to 
return more than 1024 bytes of data (especially with a wildcard search 
parameter).

> I was wondering if a workaround would be to "chain" locate messages in
> some way that is transparent to intermediate NNs that only support
> 1024 bytes. I do believe that 1024 is very limiting, however. I think
> an approach where a new CP capabilities field is defined that
> indicates support of large(r) locate sizes should be used. Locates
> would only be chained at the boundary of a large locate NN and small
> locate NN.
>

I'm not sure whether this could be implemented in a back-compatible way. 
 The obvious approach (to leave the LOCATE chain in place after the initial 
response) will not work since a broadcast chain cannot be reserved (the 
function is only available for directed searches).

> > >Following on from this, we have a fundamental worry about the way the
> > >proposal clashes with the way the DS algorithms have been designed to 
work.
> > >The introduction of the concept of multiple replies/multiple resources
> > >with the same name/wildcard searches.  The algorithms have been
> > >optimized to expect only single positive replies.
> >
> > You have a point, however the concept duplicate resources is something 
that
> > must be addressed. Imagine how nice TCP/IP would be if you did not have
> > to specify the address of a DNS. You could just issue a gethostbyname 
and
> > any available DNS would reply with the hosts IP address. It would make
> > TCP/IP
> > usable. This functionality would also make APPN usable. We cannot 
continue
> > to treat all duplicate resources as a configuration error, when some
> > resource
> > types may lend themselves to duplication.
>
> As I said before, the DS algorithms *were* designed to return multiple
> replies *and* multiple resources - even with the same name. I'm not
> entirely sure why you have such a strong objection to this, Matt,
> since I thought you guys had also gone through the patents ???
>
> > Perhaps we should stipulate that replies containing CV 3E's would not 
need
> > to be cached?
>
> Probably fair. I have a feeling someone in the architecture team might
> have a good point of view on this.
>

I agree that the concept of multiple positive replies is a vital part of the 
functionality offered by the proposal.

However, the way the DS algorithms have been implemented in the APPN 
architecture reference are fundamentally based on the assumption that only a 
single positive response is valid.  The fact that the broadcast search does 
not (at present) rely on a timeout and the way the cacheing/directed search 
mechanism has been designed to work both serve to indicate this.

We do not think that there is any obvious way the caching mechanism can be 
changed to work with the concept of multiple positive replies (other than 
removing them for "CV 3E"s)) - since after any directed search to cached 
entries it would still be required to carry out a broadcast.

Similarly we cannot see any easy ways of getting current backlevel NNs to 
allow multiple positive replies through on a broadcast search.

> > >We also have a general worry about the proposal's interaction with CDS 
and
> > >Border Node.
> > >
> > > -  The proposal assumes that all resources are required to be 
registered
> > >   with a CDS.  Otherwise searching the CDS does not help, since you 
will
> > >   have to carry out a broadcast search in any case to discover any
> > >   unregistered resources.
> >
> > Only resource of types other that LU, ENCP and NNCP would require this.
> > However, as you will note in the "Unresolved Issues" section, perhaps 
the
> > CDS should not be used at all?
>
> I too have oscillated on my thoughts about using the CDS. While using
> CDS still makes it necessary to send directed locates to each of the
> resources that match the query, I believe this is still better than a
> broadcast (especially since I think most queries would be quite
> specific - ie avoiding wild-carding). So at the moment my feeling is
> that use of the CDS is an advantage.
>

We have a number of problems with the use of CDS.

 -  In order to make use of the CDS in this way we would have to require 
every
   EN to register its resources with a NN which would in turn be required to 

   register them with a CDS.  Essentially you seem to be abolishing much of 
the
   advantages of the distributed mechanism that DS presents.

 -  The implementation CRR (Central Resource Registration) is an option at 
the
   moment.  It's not clear how wide-spread its implementation is.

 -  CDS implementation are fairly scarce (particularly since IBM has not 
released
   the specifications).

 -  There are several reasons why an EN might wish to receive all broadcast
   searches.  The resources on it might be changing frequently, and the 
overhead
   in registration would be inapropriate.  Alternatively it might be a 
Peripheral
   Border Node.

> > > -  How will the proposal interoperate with BNs?  Will all LOCATE 
requests
> > >   be fanned out to all attached networks, or will some filtering take
> > >   place?
> >
> > Good Point, this is an area not addressed by the proposal. Please 
provide
> > some recommendations.
>
> I think that Ron and I are in the same boat here - we have very little
> deep understanding of BN issues because IBM has hidden them to a great
> degree, and we are both more EN oriented. Any advice you can give here
> would be great.
>

Unfortunately our knowledge of BN internals are also fairly limited.  I 
think that this is an area that IBM developers (and especially VTAM) will 
have to address.  The compulsory use of a CDS may cause problems in this 
area, however.

> > > - will general cost less to implement, both in terms of development
> > >   costs and time to market.
> >
> > This is a sweeping statement that leads me to wonder if you have a 
vested
> > interest in an ANAME solution? I would say that this depends on many
> > variables.
> > See response to "no changes required".
>
> (and the rest of the ANAME stuff)
>
> I do strongly agree with Ron on this one. The initial thing that hit
> me in the face was that this was not an unbiased viewpoint. I take it
> that you have at least begun developing ANAME ?
>
> I know very little about ANAME, but it does appear to duplicate much
> of the function of DS. This to me would indicate that it would cost
> *more* for most people to implement, since rather than extending DS,
> they would be duplicating it (and extending it).
>

No, we haven't yet looked at implementing ANAME.  Since it is an 
application-level solution it is not an obvious candidate for us to develop. 

However, we feel that it despite its drawbacks (some of which Jim has 
pointed out) it is probably the appropriate place to implement this 
functionality (albeit in a standardised way).

> > >Aside from the interoperability problems I discussed earlier, this 
would
> > >place a tremendous burden on NNs.  To optimize performance and 
guarantee
> > >delivery an NN is required to preallocate space for all the LOCATE 
requests
> > >that it is handling.  Increasing the size of the buffer required to 
such an
> > >extent would cripple the LOCATE processing capabilities of the NN.
> >
> > I do not understand why it would cripple an NN capabilities? I would 
tend to
> > believe that it would significantly enhance an NN's capabilities. 
However,
> > any and all alternatives solutions are welcome.
>
> I do not understand either. I would have thought that if pacing were
> performed in the architected manner, then RUs in the pacing windows
> are the only ones that would need to be pre-allocated. Apart from
> this, a control block is needed to track the locate, but this is
> needed regardless of how large the locate size is.
>
> Since the size of the pacing window is up to the receiver, and NNs
> that are constrained in memory (ie small real memory only) will
> typically have only a few NN-NN connections, surely the 32KB hit is
> not too high ? In any case, I believe we can do a lot better than
> 1024.
>

It is true that it would be possible to implement a NN in this way.  However 
in a large network there are likely to be large numbers of LOCATEs being 
processed by an NN at any particular time.  In order to optimise performance 
throughout the network it is extremely desirable for the NN to avoid 
throttling back adjacent NNs with pacing since this will simply cause them 
storage problems. Instead is is better to preallocate storage in which it 
can reassemble received LOCATE replies.

> > >The "best" resource to use cannot be determined without route 
computation.
> > >(For example, some resources may not be reachable with a particular 
COS.)
> >
> > I do not believe this is true. Since all locate/locate replies flow at
> > network priority (all locates being equal that is), the first reply
> > could be considered to be the best at any point in time. A route
> > calculation may occur (using the specified Mode/COS) following the
> > completion of the locate (depending on wether the locate was
> > connection or query driven). If the route calculation fails then the
> > next positive reply could be used to calculate a route (continuing
> > until a resouce was found that a route could be calculated to).
> >
> > I do not believe that route calculation within APPN can ever guarantee
> > the best route (or resource) since networks are dynamic in nature. The
> > best route (or
> >
> > resource) can change from moment to moment. APPN can only hope to make
> > a best guess based on available information (route resistance etc.).
>
> I think Matt is right. The application (TP) may specify a particular
> MODE, which in turn specifies a particular COS. Just because we can
> get back responses on the CPSVCMG COS connections does not necessarily
> mean that a route exists to the resources using the TP supplied
> COS. Irrespective of that, as Matt pointed out, the order of responses
> using the CPSVCMG COS may be way off-beam in terms of the best
> resource using the TP supplied COS. So I think route computation will
> be necessary.
>

We agree.

I will not be at the AIW next week but both Neil Collin and Mike Evans from 
Data Connection will be there to continue the discussion.

Matthew.

---

From: Dave Finnie <[email-masked]>
Date: Wed, 16 Aug 1995 13:26:24 +1000

Rather than build to some large responses to responses, I'm doing
selective editing. Hopefully I haven't lost the train of thought in
doing so...

> return more than 1024 bytes of data (especially with a wildcard search 

Yes, that too.

> function is only available for directed searches).

It's possible that I'm misunderstanding the architecture here, so
correct me if I'm wrong (anyone):

Yes, reservation is only allowed for directed searches, but this
relates to keeping the locate chain after the last (ie complete)
reply.

I don't see anything in the architecture preventing multiple responses
to a broadcast, since positive replies can be returned until a
complete neutral reply is returned.

Am I mis-reading ?

> mechanism has been designed to work both serve to indicate this.

But isn't this assumption only valid for the ONN ? The intermediate
NNs simply propagate positive replies (as many as are received) until
it receives complete replies from all of its children. So all that
needs to change are the NNs whose domain LUs need the new function.

> entries it would still be required to carry out a broadcast.

Can't a cached entry exist for each resource type returned on a
positive reply ? Clearly the caching mechanism internal to the node
would need to be enhanced to allow multiple resources with the same
name.

I think that perhaps cached entries could be used here. If an
initiating resource (TP) performs a CMCNSRV, and no wild-cards are
specified, the ONN could check its cached entries, and if not too old,
calculate the best route to each that match, and use the best
resource. Once a cached entry is determined to be too old
(implementation-specific), the CDS will be checked, or broadcast
performed. Of course, the longer lived the cached entries are allowed
to be, the less "dynamic" the network is, and the less network traffic
will be to find the resource. The shorter lived, the more dynamic, and
the more network traffic.

I really think that if searching for non-LU resources were used by
applications in the manner proposed (CMCNSRV, for example), that most
of the time the application would be quite specific about what it
wants to connect to. The query service (wild carding) is a very useful
one, but something that would be used less often.

> allow multiple positive replies through on a broadcast search.

See my thoughts above on receiving multiple positive replies.

>     every EN to register its resources with a NN which would in turn
>     be required to register them with a CDS.  Essentially you seem to
>     be abolishing much of the advantages of the distributed mechanism
>     that DS presents. 

Yes, but this is a function of the CDS, rather than the proposal. If a
CDS exists in the network, all NNs will refer to it unless they have a
cached entry already. See my discussion above for ways of using cached
multiple entries under the proposal.

>     the moment.  It's not clear how wide-spread its implementation is.

Fair enough. Should be able to do a quick poll at AIW 8.

>     released the specifications).

Yes, I agree. This is a problem. *If* we want to continue with the
idea of CDS (looks like one of the cows is already sick :-)) then
perhaps IBM could be persuaded to release this info.

>     overhead in registration would be inapropriate.  Alternatively it
>     might be a Peripheral Border Node.

Yes, good point.

> functionality (albeit in a standardised way).

Fair enough. Sounds like a good candidate for discussion at the AIW.

> can reassemble received LOCATE replies.

Because of the high priority of the CPSVCMG COS, pacing window sizes
do not need to be large for inter-network node links. Also, NNs that
do have tight memory constraints will typically have only a handful of
connections. Therefore, the number of pacing RU buffers required is
(av. pacing window size) * (number of links). Of course, this is very
simplistic, but I think reasonably accurate.

Therefore, it would seem to me that NNs are better off not
pre-allocating receive buffers for locate replies, since, as you have
quite rightly pointed out, the number of concurrrent locates could be
quite high, whereas the value in my calculation above should be quite
low, and more importantly - relatively constant.

So I still feel that, in 1995, 32KB per message is not an absolutely
huge constraint on memory in NNs. Having said this, however, at network
priority, it certainly is taking a chunk out of the available
bandwidth. Perhaps 32KB is not the right value, but neither do I feel
that 1024 is, either. Perhaps there is some middle ground that
everyone would be happy with ?

Unfortunately I won't be at AIW 8 either, but I think Ron has a good
understanding of my views for this function.

Dave